Seems strange that we added 'DefaultVersion string yaml:"default_version"' to the pluginConfig and it is not about 'loading the full plugin configuration' or something. And there is this method exclusively about the runtimes.

I guess it does not hurt, but would expect, that if we are making this changes, the init to be the spot that you would load the plugins configurations and use them. Why have an hardcoded list on the init, and then load them just for the default_version? Might as well, load them, and use them.

Checking if some tools like 'enigma' we can add an optional 'enableByDefault' or something that would be off for the ones we don't want to add automatically

First two points are addressed

3rd one looks like candidate for another PR, we can discuss it 👍

🚫 Codacy found a high Security issue: When working with web applications that involve rendering user-generated content, it's important to properly escape any HTML content to prevent Cross-Site Scripting (XSS) attacks.

The issue identified by the Semgrep linter is related to the potential for Cross-Site Scripting (XSS) attacks when rendering user-generated content with the text/template package in Go. If user input is not properly escaped, it could lead to the injection of malicious scripts that execute in the user's browser.

To mitigate this risk, you should use the html/template package instead of the text/template package. The html/template package automatically escapes HTML content, providing an additional layer of security against XSS attacks.

Here is the code suggestion to fix the issue:

This comment was generated by an experimental AI tool.

🚫 Codacy found a high ErrorProne issue: path.Join(...) always joins using a forward slash.

The issue identified by the Semgrep linter is that the path.Join(...) function in Go always uses forward slashes (/) as path separators, regardless of the operating system. This can lead to problems on Windows systems, where the standard path separator is a backslash (\). Therefore, using path.Join with a filename that may contain backslashes can result in incorrect paths.

To fix this issue, we can use filepath.Join instead of path.Join, as filepath.Join will use the correct path separator for the current operating system.

Here's the code suggestion to fix the issue:

This comment was generated by an experimental AI tool.

🚫 Codacy found a high ErrorProne issue: path.Join(...) always joins using a forward slash.

The issue identified by the Semgrep linter is that path.Join(...) uses forward slashes (/) as the path separator, which can lead to incorrect paths on Windows systems where the expected separator is a backslash (\). This can cause problems when the resulting path is used to access files on the filesystem.

To fix this issue, you can use filepath.Join(...) instead of path.Join(...). The filepath package automatically uses the correct path separator for the operating system on which the code is running.

Here’s the suggested code change:

This comment was generated by an experimental AI tool.

🚫 Codacy found a high ErrorProne issue: path.Join(...) always joins using a forward slash.

The issue identified by the Semgrep linter indicates that path.Join(...) is being used to concatenate paths, but it is being done with a hardcoded string "python" that may not be compatible with the operating system's path separator. In Go, path.Join is intended for use with paths that should be treated as POSIX-style paths (using forward slashes), while filepath.Join should be used for file paths that are OS-aware and will use the correct separator for the current operating system.

To fix the issue, you should replace path.Join with filepath.Join, which will ensure that the correct path separator is used based on the operating system.

Here's the suggested code change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium Complexity issue: Method GetDownloadURL has 7 parameters (limit is 5)

The issue identified by the Lizard linter is related to the number of parameters in the GetDownloadURL function. Having too many parameters can make the function harder to use and understand, as well as increase the cognitive load for anyone maintaining the code. The limit set by the linter suggests that functions should ideally have no more than 5 parameters.

To address this issue, we can encapsulate the parameters into a single struct, which will reduce the number of parameters in the function signature. Here's a code suggestion that implements this change:

In this suggestion, we assume that templateData is a struct that contains all the necessary fields (like FileName, Version, MappedArch, etc.) that were previously passed as separate parameters. You would also need to create an instance of templateData before calling GetDownloadURL.

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is being used to output information. While Write-Host works for displaying messages to the console, it is not recommended because it doesn't allow for capturing or redirecting output, and may not function correctly in all environments or hosts. Instead, it's better to use other cmdlets like Write-Output, Write-Verbose, or Write-Information, which provide more flexibility and are more suitable for scripting.

To address this issue, you can replace the Write-Host command with Write-Output for the specific line flagged by the linter.

Here's the suggested code change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is used to output messages. While Write-Host can display messages to the console, it has limitations: it does not allow for capturing or redirecting output, and it may not function correctly in all environments or hosts. Instead, it's recommended to use Write-Output, Write-Verbose, or Write-Information for better flexibility and compatibility.

To address this issue, you can replace Write-Host with Write-Information, which is more suitable for logging informational messages that can be captured or redirected.

Here's the suggested code change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer is that Write-Host is not recommended for use because it directly writes to the console and cannot be captured or redirected. This can lead to problems in scripts where output needs to be processed or logged. Instead, it is better to use Write-Output, Write-Verbose, or Write-Information which provide more flexibility in handling output.

To fix the issue, you can replace the Write-Host command with Write-Output. Here’s the suggested change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer is that Write-Host is being used to output messages. While Write-Host directly writes to the console, it has limitations: it does not allow for output to be captured, redirected, or suppressed, which can lead to issues in automated scripts or environments without a host. The recommended practice is to use Write-Output, Write-Verbose, or Write-Information instead, which provide more flexibility in handling output.

To fix the issue, we can replace Write-Host with Write-Output in the specified line.

Here’s the code suggestion:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is generally discouraged because it outputs directly to the console and cannot be captured or redirected. This can lead to problems in environments where the output needs to be processed or logged. Instead, it is recommended to use Write-Output, Write-Verbose, or Write-Information, which provide better flexibility and usability in scripts.

To address this issue, you can replace Write-Host with Write-Output. Here's the code suggestion:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that the Write-Host cmdlet is being used to output information to the console. While Write-Host does display messages, it has limitations: it does not work in all PowerShell hosts, cannot be captured or redirected, and is not suitable for logging or outputting information that may need to be processed further. Instead, it is recommended to use Write-Output, Write-Verbose, or Write-Information for better compatibility and flexibility.

To resolve this issue, you can replace Write-Host with Write-Output for the specific line mentioned. Here’s the code suggestion:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is being used to output information to the console. While Write-Host can display text to the user, it has several limitations: it does not allow for redirection, capturing, or suppression of output, which can lead to issues in scripts that need to log information or run in different environments. Instead, it's recommended to use other cmdlets like Write-Output, Write-Verbose, or Write-Information for better flexibility and compatibility.

To resolve this issue, you can replace Write-Host with Write-Output, which allows the output to be captured or redirected if needed.

Here is the suggested code change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by PSScriptAnalyzer is that Write-Host is not recommended because it directly writes to the console and does not allow for output redirection, capturing, or suppression. This can lead to problems in scripts that are intended to be more flexible or reusable in different contexts, such as when they are run in environments without a console or when the output needs to be processed further.

To address this, you can replace Write-Host with Write-Output, which is more versatile and allows the output to be captured or redirected.

Here's the suggested code change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is being used to output information to the console. While Write-Host does display text directly to the host, it has limitations such as not being able to be captured or redirected, which can lead to issues in scripts that may be run in different environments or contexts. The linter suggests using Write-Output, Write-Verbose, or Write-Information instead, as these cmdlets provide more flexibility and are better suited for scripting.

To resolve this issue, you can replace Write-Host with Write-Output, which allows the output to be captured or redirected if necessary.

Here is the suggested single line change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer is that Write-Host is not recommended for outputting messages in PowerShell scripts because it writes directly to the console and cannot be redirected or captured. This can lead to problems in environments where the script's output needs to be processed further or logged. Instead, it is advisable to use Write-Output, Write-Verbose, or Write-Information, which provide more flexibility and are better suited for scripting.

To resolve this issue, you can replace Write-Host with Write-Information, which is a more appropriate choice for logging informational messages.

Here's the code suggestion to fix the issue:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer is that Write-Host is being used to output messages to the console. While Write-Host is suitable for displaying information directly to the user, it has limitations such as not being able to redirect output or capture it in a pipeline. Instead, it is recommended to use Write-Output, Write-Verbose, or Write-Information, which are more versatile and provide better control over output.

To fix the issue, we can replace Write-Host with Write-Output, which will allow the message to be captured or redirected if needed.

Here's the code suggestion:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is being used to output information to the console. While Write-Host does display messages directly to the host, it has limitations. Specifically, it may not work in all environments, cannot be captured or redirected, and prior to PowerShell 5.0, it could not be suppressed. The recommendation is to use Write-Output, Write-Verbose, or Write-Information instead, which are more versatile and suitable for scripting.

To address this specific line of code, we can replace Write-Host with Write-Output. Here's the single line change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer is that Write-Host is being used to output messages to the console. While Write-Host can display information to the user, it is not the best practice for logging or outputting information in PowerShell scripts because it does not allow for the output to be captured, redirected, or suppressed. Instead, it is recommended to use Write-Output, Write-Verbose, or Write-Information for better flexibility and compatibility.

To address this issue, we can replace Write-Host with Write-Information, which is a more suitable alternative for logging informational messages. Here is the single line change to fix the issue:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is being used for outputting messages. Write-Host directly writes to the console and is not suitable for scenarios where output needs to be captured, redirected, or suppressed. Instead, it is recommended to use Write-Output, Write-Verbose, or Write-Information for better flexibility and compatibility.

To fix the issue, you can replace Write-Host with Write-Output in the line where the current directory structure is being printed. This change will allow the output to be captured or redirected if needed.

Here's the suggested code change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is being used to output information to the console. While Write-Host works for displaying messages directly to the host, it has limitations, such as not being able to redirect output or capture it in a pipeline. This can lead to problems in scenarios where you want to log information or use the output programmatically. Instead, it's recommended to use Write-Output, Write-Verbose, or Write-Information, which are more flexible and can be used in a variety of contexts.

To resolve this issue, you can replace Write-Host with Write-Output for the line that outputs the PowerShell version. This will allow the information to be captured or redirected if necessary.

Here’s the suggested code change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is generally discouraged because it writes directly to the console and does not allow for output redirection or capturing. This can lead to problems in different PowerShell hosts or when running scripts in environments where console output is not available. Instead, it is recommended to use Write-Output, Write-Verbose, or Write-Information for better compatibility and flexibility.

To fix the issue, you can replace Write-Host with Write-Output, which allows the output to be captured or redirected. Here’s the suggested change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by PSScriptAnalyzer is that Write-Host is being used for output. While Write-Host displays information directly to the console, it has limitations such as not being able to redirect output or work in all environments. Instead, it is recommended to use Write-Output, Write-Verbose, or Write-Information, which provide more flexibility and are better practices for script output.

To resolve this issue, you can replace the Write-Host command with Write-Output for the line that produces the "Resolved paths:" output. This change allows the output to be captured or redirected if needed.

Here's the suggested code change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by PSScriptAnalyzer is that Write-Host is not recommended for outputting information in PowerShell scripts because it writes directly to the host's console, making it difficult to capture or redirect the output. This can lead to issues in environments where the script might be run in different contexts (e.g., automated scripts, logging, etc.). Instead, it's better to use Write-Output, Write-Verbose, or Write-Information for more flexible output handling.

To fix the issue in the provided code, you can replace Write-Host with Write-Output. Here’s the suggested change:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer linter is that Write-Host is not recommended for outputting information because it is not suitable for all PowerShell hosts and cannot be redirected or captured. Instead, it's better to use Write-Output, Write-Verbose, or Write-Information for better compatibility and flexibility in handling output.

To address this issue, you can replace Write-Host with Write-Output, which allows the output to be captured or redirected if needed.

Here's the code suggestion to fix the issue:

This comment was generated by an experimental AI tool.

⚠️ Codacy found a medium BestPractice issue: File 'run.ps1' uses Write-Host. Avoid using Write-Host because it might not work in all hosts, does not work when there is no host, and (prior to PS 5.0) cannot be suppressed, captured, or redirected. Instead, use Write-Output, Write-Verbose, or Write-Information.

The issue identified by the PSScriptAnalyzer is that Write-Host is not recommended for outputting information in PowerShell scripts because it writes directly to the host and cannot be captured, redirected, or suppressed. Instead, it's better to use Write-Output, Write-Verbose, or Write-Information, which are more flexible and compatible with various environments.

To fix the issue, you can replace Write-Host with Write-Output. Here's the single line change:

This comment was generated by an experimental AI tool.